【資料公開】PCI DSSの認証認可に関する要件とそのための実装を学ぶ勉強会をやりました（インフラ編）
中山（順）です
今回もPCI DSSに関する勉強会の続きです。
【資料公開】PCI DSSの認証取得を目指す方へ！AWSの利用を前提としたパッチ管理について考えるクローズドな勉強会をやりました
今回はその続きとして、認証認可をテーマに勉強会を実施しました。
参加メンバーは引き続き弊社AWS事業本部コンサルティング部のメンバー ＋ とあるQSAの皆様です。
IAMによるデータへのアクセス制御については、弊社臼田が担当しました。
私はAWSのレイヤーにおける認証認可について解説しました。資料はこちらです。
勉強会のスコープ
PCI DSSにおいて、認証認可に関する要件は要件7と8にほぼ集約されています。
要件7は、人に対して必要最小限度の権限を付与することを求めています。 要件8は、権限を付与したユーザーを適切に識別・認証することを求めています。
勉強会はAWSの機能で要件をどこまで満たせるかを知り、そして考えることが目的なので、ドキュメンテーションや運用についてはスコープ外とします。
解説したこと
私のパートでは、IAMの機能をPCI DSSの要件に沿いつつ紹介しました。
感想
勉強会の中で以下のようなコメント／議論がありました。
IAM Roleが理解しにくい
これは私も苦労しました・・・（遠い目
IAM Roleは、それ自体では認証はせず、権限を委任できるユーザー／委任できる権限を定義しているものです（認可だけやってる）。 STSから発行される一時認証情報を利用してIAM Roleの権限を行使することになり、またマネージメントコンソールでのスイッチロールではその実体（一時認証情報）に触れることがないため理解することが難しいのだと思います。
PCI DSSにおいては、誰に権限を付与しているのかを可視化することが非常に重要となります（要件7.1）。 IAM Roleを利用している場合、IAM User/Group/Policyだけを利用して権限管理をしている場合と比較して全体像がわかりにくくなるように思います。 かといって、マルチアカウント環境において各アカウントで認証を行うと別のリスクが大きくなりますので、 IAMだけでうまく設計するなり外部のIdPと連携するなどして要件に対応していく必要があるでしょう。
Identity-based Policy「だけではない」
権限がユーザーにだけ紐付くのであれば話は簡単なのですが、AWSではリソース側に権限を付与するケースもあります。 S3のバケットポリシーがその代表的な例です。 Resource-based Policyの場合、「誰に」の部分はprincipal要素で定義します。 また、権限の評価ロジックは資料内でも記載した通りで、思いのほか複雑です。 可能な限りIdentity-based Policy側に寄せるなど、考えて権限設計を行わないとわかりやすさが低下してしまうでしょう。
新サービス／機能追加と権限管理への影響
Systems Manager Session Managerを例に挙げておりますが、 これらの機能が非常に便利なのですが、これを利用させるということは仮想マシン「内」において非常に強い権限を与えることになります。 IAM Policyで下手にワイルドカードを利用して権限を付与していると、意図せずにこれらの権限を与えてしまう可能性があります。 資料ではRDSにアクセスするため認証トークンを発行する例も示しておりますが、 AWSのリソースに対する操作権限だけでなくリソース「内」への操作権限もIAMで付与できることを認識することが重要という認識を共有しました。 ちなみに、いずれも権限の付与以外に前提条件を満たす必要があり、IAMで権限を付与するだけではこれらの操作が可能になることはありません。
できないこともある（ユーザーのロックアウトなど）
AWSの機能だけでは満たせないこともあります。
例えば、認証に連続して失敗した場合にそのユーザーをロックアウトするような機能はAWSにはありません。 こういったケースに対応するためには、サードパーティの認証プロバイダーを利用するなど、他の手段を検討するといいでしょう。
なお、代替コントロールとしてMFAを利用することも考えられるかと思いますが、別に挙げられている要件を代替コントロールとすることはNGとのことです。
ルールや運用ではなく、仕組みで解決することが重要
PCI DSSでは、認証強度を保つために適切なパスワードポリシーが設定されることを要求しています。 パスワードポリシーの管理については、変更権限を管理者にしか付与しないことで適切な状態が維持できるかと思います。
このように、機能で適切な状態を維持できるケースは良いのですが、適切な運用を行わないとリスクが発生するケースもあります。 例えば、IAM Userに対してマネージメントコンソールにログインするためのパスワードを発行する際に、初回ログイン時にパスワード変更を強制させることが可能です。 ただし、IAMの管理者がその設定を利用しないと初期パスワードのまま利用されてしまうケースが発生します。
つい先日も初期パスワードが変更されていないことを利用した不正アクセスの事案が発生しています。
長崎県職員による業務ネットワークへの不正アクセスについてまとめてみた
このように、人間がルールを守ることを前提とした運用ではインシデントが発生する確率が高まってしまいます。 利用者も管理者も人間です。 「人間が最も脆弱なコンポーネントである」くらいの認識で設計するといいのではないかと思います。
まとめ
今回も勉強会の実施にあたってPCI DSSの監査要件を踏まえてAWSの機能を改めて整理して勉強会に臨みました。 監査者の立場から意見を頂くことで、お客様に対して「AWSの機能でどこまでできるのか／どのようなリスクが残存しうるのか」をこれまでよりも説明できるようになった気がします。 やはり他流試合は良いものなので、皆さんもやってみてはどうでしょうか？
